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Abstract — This paper presents a DSL for geometric rela- 
tions between rigid bodies such as relative position, orien- 
tation, pose, linear velocity, angular velocity, and twist. The 
DSL is the formal model of the recently proposed semantics 
for the standardization of geometric relations between rigid 
bodies [1], [2], referred to as 'geometric semantics'. This 
semantics explicitly states the coordinate-invariant properties 
and operations, and, more importantly, all the choices that 
are made in coordinate representations of these geometric 
relations. This results in a set of concrete suggestions for stan- 
dardizing terminology and notation, allowing programmers 
to write fully unambiguous software interfaces, including 
automatic checks for semantic correctness of all geometric 
operations on rigid-body coordinate representations. 

The DSL is implemented in two different ways: an external 
DSL in Xcore and an internal DSL in Prolog. Besides defining 
a grammar and operations, the DSL also implements con- 
straints. In the Xcore model, the Object Constraint Language 
language is used, while in the Prolog model, the constraint 
are natively modelled in Prolog. 

This paper discusses the implemented DSL and the tools 
developed on top of this DSL. In particular an editor, checking 
the semantic constraints and providing semantic meaningful 
errors during editing is proposed. 

I. Introduction 

When developing robotic applications, robot program- 
mers and application developers have to deal with three- 
dimensional motion and relations between rigid bodies 
(manipulated objects, robot links, or mobile bases). Rigid 
bodies are essential primitives in the modelling of robotic 
devices, tasks and perception. Basic geometric relations 
between rigid bodies include relative position, orientation, 
pose (combining position and orientation), linear velocity, 
angular velocity, and twist (combining linear and angu- 
lar velocity). To express geometric relations and perform 
mathematical operations on them (e.g. composition of 
relative motion, time differentiation, or integration), robot 
programmers have to choose coordinate representations 
with which to perform the corresponding numerical op- 
erations. 

Until recently, and despite a history of over 50 years, 
the geometric properties of rigid-body operations, and their 
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coordinate representations, were not standardized, which 
has led to a proliferation of mutually incompatible software 
libraries, in the robot control products of commercial 
manufacturers as well as in open source libraries such 
as KDL (Kinematics and Dynamics Library) [3], ROS 
(Robot Operating System) [4], RL (Robotics Library) [5], 
All geometric relations and their coordinate represen- 
tations entail a surprisingly large number of choices or 
assumptions, which are often made implicitly, but which 
are necessary to consider in view of (i) understanding the 
physical meaning of the numerical values that constitute 
the coordinate representation of a geometric relation and 
(ii) performing physically meaningful mathematical opera- 
tions on these numerical values. Not explicitly stating the 
above assumptions may lead to errors in the calculations 
(composition of geometric relations expressed in different 
coordinate frames, composition of poses and orientation 
coordinate representations in wrong order,. . . [1]). To al- 
leviate this problem, we recently proposed semantics for 
the standardization of geometric relations between rigid 
bodies [1], referred to as 'geometric semantics'. This se- 
mantics explicitly states the coordinate-invariant properties 
and operations, and, more importantly, all the choices that 
are made in coordinate representations of these geometric 
relations. This results in a set of concrete suggestions 
for standardizing terminology and notation, allowing pro- 
grammers to write fully unambiguous software interfaces, 
including automatic checks for semantic correctness of all 
geometric operations on rigid-body coordinate representa- 
tions. This resulted in a Robot Request for Comments [2] 
for the Robot Engineering Task Force [6]. Furthermore, 
software providing a C++ implementation of the software 
is developed and available as open-source [7], [8]. 

Domain Specific Languages are lightweight program- 
ming languages designed to concisely express the con- 
cepts of a particular domain. Commonly two types are 
distinguished: internal and external DSLs. The former are 
built on top of an existing language, while the latter are 
developed from scratch resulting in a custom syntax and 
making them independent from existing languages. By 
reusing existing infrastructure, internal DSLs are easier 
to create, maintain, and combine with other DSLs than 
external ones [9]. External DSLs, while suffering from 
an increased cost for creating and maintenance, are not 



constrained by any other language. Therefore, the choice 
between an internal or external design often depends on 
the particular application, use case, available tools, and 
preferences of the designer. In this paper we develop both 
types for the geometric semantics: 1) an external DSL in 
Xcore and 2) an internal DSL in Prolog. 

The goal of this paper is fourfold. Firstly, we want 
to build a DSL for geometric relations between rigid 
bodies such as relative position, orientation, pose, linear 
velocity, angular velocity, and twist founded on the geo- 
metric semantics [1], [2]. This DSL advances with respect 
to the available available implementation in the general- 
purpose programming language C++, by formalizing the 
underlying model of the geometric semantics. Furthermore, 
the DSL is the basis for the developments of tools that 
assist the robot programmers and application developers to 
write fully unambiguous software interfaces and prevent 
common errors in geometric calculations. In particular this 
paper presents and editor built on top of the proposed 
DSL that automatically checks the semantic correctness of 
all geometric operations on rigid-body coordinate repre- 
sentations, while writing and editing the code. Secondly, 
we want to explore the impact of different design choices 
(internal, external), work flows, and tools. Thirdly, we 
believe that due to the concise and mature nature of the 
underlying geometric semantics theory and its relevance 
for the robotics domain it will prove to be an excellent 
example for future DSL development in robotics. Fourthly, 
we will highlight the unfulfilled robotic needs still present 
in Model Driven Engineering. 

Section [II| gives an overview of related work. Section [TV 
provides a short summary of the geometric semantics 
theory relevant for this paper. Section [ill] situates this 



paper's contributions using the four levels of abstraction 
in Model Driven Engineering. 

II. Related work 

Since we are not aware of any DSL on the semantics for 
geometric relationships between rigid bodies, our related 
work will rather point to some other DSLs developed in 
the robotics domain. 

Frigerio et al.'s DSL is the DSL most related to the 
DSL proposed in this paper. They propose a DSL for kine- 
matic models and fast implementation of robot dynamic 
algorithms. The DSL allows to model algorithms that 
are parametrised on the kinematics/dynamics model of a 
robot, hereby facilitating the generation of executable code 
tailored for a specific robot. This approach only requires 
the users to provide a high level description of their robot 
and relieves them from hand-crafted development. 
Furthermore, we want to mention the Mechatronics De- 
scription Language (MDL), which is a domain- specific 



language that can model the kinematic structure of individ- 
ual robot modules and declaratively describe their possible 
interconnections. From this description, the MDL compiler 
generates the code that is needed to simulate the resulting 
robots within Webots, a widely used commercial robot 
simulator, and the software component needed for spatial 
structure computations by a virtual machine-based runtime 
system, which we have developed and use for programming 
physical modular robots [10]. 

Klotzbiicher et al. [11] propose a DSL for specifying 
robotic tasks using the task frame formalism as an example 
of lua as a lightweight and composable metamodelling 
language for specification and validation of internal DSLs. 
In later work Klotzbiicher et al. [9]) propose a DSL 
allowing to separate task specification and coordination of 
these tasks using state charts. 

III. Levels of abstraction in Model Driven 
Engineering 

Figure [T] illustrates a systematic approach to model a 
certain domain in four levels of abstraction [9], [12]. These 
four levels have the following meaning for the context of 
the geometric semantics: 

MO: the level of the concrete implementations, for instance 

a particular set of geometric semantics calculations 

using the C++ library of the geometric semantics [8], 

Ml: the level of a particular set of geometric semantics 

calculations using the geometric semantics DSL, 
M2: the level of the application independent geometric 
semantics DSL, which provides a language for both 
coordinate representation independent and dependent 
(taking into account the constraints of a particular 
coordinate representation) geometric calculations. 
M3: the highest level of abstraction, that is, the model in 
terms of which we describe our meta-models (M2). 
For example, ecore that we can use to describe our 
geometric semantics DSL. 
The geometric semantics theory [1], summarized in 
Section [IV| can be considered as the basis for the M2 
level DSL, as it describes (in language) the constraints 
on the geometric relations semantics, the possible oper- 
ations on the geometric relations, the constraints on the 
relations and operations, and the constraints imposed by 
particular coordinate representations. The available C++ 
implementation [8] and the applications implemented in 
it, are examples of the MO level. 

This paper provides DSL implementations, both an 
external DSL and an internal DSL, on the M2 level. 
Furthermore, this paper presents tools based on the de- 
veloped DSLs, that allow the DSL users to implement 
their particular set of geometric semantic calculations, 
i.e. to work on the Ml level. To illustrate the proposed 
approach, we provide an example on a Ml implementation 
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Fig. 1: The four levels of abstraction.) 



for a particular geometric calculation and show how the 
developed DSL and the accompanying tools will help to 
prevent commonly made errors. 

IV. Geometric semantics, background [1] 

A. Geometric relations 

Geometric relations between bodies are described us- 
ing a set of geometric primitive sq points (e), vectors, 
orientation frames ([a] , they represent an orientation, by 
means of three orthonormal vectors indicating the frame's 
X-axis X, Y-axis Y, and Z-axis Z), and frames ({#}). 
Figure [2] presents the geometric primitives body, point, 
vector, orientation frame, and frame graphically. To help 
the reader we will consistently use the following naming 
for the geometric primitives to represent the geometric 
relation of a body C with respect to body D in this 
document: e|C, [a]|C, {g}\G, f\D, [b]\T>, and {h}\D. 

Table [I] summarizes the minimal but complete set of 
geometric primitives and the (coordinate) semantics for 
the geometric relations position, orientation, pose, twist 
between rigid bodies, which are the most relevant relations 
for this paper. 

B. Semantic operations 

On the geometric relations defined in Section |IV-A 



semantic operations that compose the geometric relations 
or that change the point, orientation frame, reference point, 
reference orientation frame, or coordinate frame of the ge- 
ometric relation can be applied. These semantic operations 
themselves impose constraints on the geometric relation 
they are applied to and on the operation arguments (which 
are themselves geometric relations) of the operator. While 

^his background contains a short summary of the semantics for the 
standardization of geometric relations between rigid bodies, for more 
details we refer to [1]. 




Fig. 2: The geometric relation between rigid bodies are de- 
scribed using a set of geometric primitives: points, vectors, 
orientation frames, and frames. The above figure shows the 
geometric primitives that are useful to define the position, 
orientation, pose, linear velocity, angular velocity, and twist 
of body C with respect to body D: an orientation frame [a], 
a point e, and frame {g} fixed to body C, an orientation 
frame [&], a point /, and frame {h} fixed to body D, and 
a coordinate frame [r], considered instantaneously fixed to 
body D, in which the coordinates are expressed. (Extract 
from [1].) 



[1] provides an overview of semantic operations that can 
be applied to geometric relations and lists the constraints 
imposed by the operations, we will only give an example 
illustrating the concept of the semantic operation and the 
constraints imposed by it. 

As an example, consider the semantic operation 
to change the point used to describe the posi- 
tion of body C with respect to body D. Imagine 
PositionCoord(ei|C,/|D, [r]) is the semantic description 
of the position of body G with respect to body D. To 
change the point to describe the position from the current 
point ei to a new point e^, the position of the new 



Geometric Relation (Coordinate) semantics 



Geometric primitives 



Graphical representation 



Position 



Position (e|C, f\T>) 
PositionCoord (e|C, f\D, [r]) 



point e 
body C 

reference point / 
reference body 2) 
coordinate frame [r] 
Position of point e fixed to body C (e\G) with respect to point f fixed to body T> (f\D), expressed in coordinate frame [r] 



Orientation ([a] |C, [b] p) 
OrientationCoord ([a] |C, [6] p, [r]) 



Orientation Orientation (fa| |C, [61 \T>) orientation frame [a] 

body e 

reference orientation frame [b] 

reference body D 

coordinate frame [r] 
Orientation of orientation frame [a] fixed to body C ([a] \G) with respect to orientation frame [b] fixed to body T> ([b] \*D), expressed 
in coordinate frame [r] 

Pose Pose ((e, [a]) |C, (/, [b]) p) point e 

PoseCoord ((e, [a]) |C, (/, [&]) p, [r]) orientation frame [a] 

body 6 

reference point / 
reference orientation frame [b] 
reference body T> 
coordinate frame [r] 

Pose of point e and orientation frame [a] fixed to body C f (e, [a])|CJ with respect to point f and orientation frame [b] fixed to body 
D ((/, [6])pJ, expressed in coordinate frame [r] 



Pose (M|e, (MP) 
PoseCoord ({g}\e,{h}\1),[r]) 



frame {g} 
body e 
frame {h} 
reference body T> 
coordinate frame [r] 
Pose of frame {g} fixed to body C ({g}|CJ with respect to frame {g} fixed to body T) ({g}\D), expressed in coordinate frame [r] 





Linear velocity 



Linear Velocity (e|C, T>) 
LinearVelocity Coord (e|C, 2), [r]) 



point e 
body e 

reference body 1) 
coordinate frame [r] 
Linear velocity of point e fixed to body C (e\Q) with respect to body T), expressed in coordinate frame [r] 



Angular velocity Angular Velocity (6, T>) body 6 

Angular Velocity Coord (C, T), [r]) reference body T> 

coordinate frame [r] 
Angular velocity of body C with respect to body T>, expressed in coordinate frame [r] 



Twist 



Twist (e|e, T>) 
TwistCoord(e|e,D, [r]) 



point e 
body e 

reference body T> 
coordinate frame [r] 
Twist of body C with velocity reference point e (e\G) with respect to body D, expressed in coordinate frame [r] 






p) \/V 



TABLE I: Minimal semantics and coordinate semantics (expressed in coordinate frame [r]) including the minimal but 
complete set of geometric primitives for the position, orientation, pose, linear velocity, angular velocity, and twist of 
body C with point e, orientation frame [a], and frame {g} with respect to D with point /, orientation frame [b], and 
frame {h}, including a graphical representation, (extracted from [1]) 



point e2 fixed to body C with respect to ei fixed to 
body C and expressed in the same coordinate frame [r] is 
needed, i.e. PositionCoord (e2|C, ei|C, [r]). If the semantic 
operator .changePoint () is applied to the geometric relation 
of which the point has to be changed (in our example 
PositionCoord (ei|C,/|D, [r])) and has as an argument the 
geometric relation needed to achieve this change of ref- 
erence point, the .changePoint () imposes the following 
constraints: (1) the argument of .changePoint () should be 
a PositionCoord geometric relation; (2) the reference point 
of the argument should be equal to the point of the position 
the operator is applied on; (3) the body of the argument 
should be equal to the body of the position the operator is 
applied on; (4) the reference body of the argument should 
be equal to body of the position the operator is applied on; 
and (5) the coordinate frame of the argument should be 
equal to the point of the position the operator is applied 
on. This can be visually illustrated as follows: 



PositionCoord (e 2 |e,/p, [r]) = 



PositionCoord 



. changePointPosition ( 



(ei|£,/P, 

PositionCoord ^e 2 |e,ei|g, rj) 



(1) 



the semantic constraints imposed on the geometric relation 
the operation is applied to, and on the operation arguments, 
are shown by using the same names for the geometric 
primitives when equality of the primitives is imposed, 
furthermore the lines indicate ones again the geometric 
primitives that should be equal to obtain a semantically 
correct operation. 

V. Geometric semantics DSL (M2) and the 
tooling (Ml) 

A. External DSL 

1) DSL design: The external DSL is developed using 
Xcore. As this DSL is not using the Java specific syntax 
parts of Xcore, it can be considered as a plain text file 
and therefore as an external DSL. The geometric semantics 
DSL uses the Object Contraint language (OCL) DSL to 
define the constraints in the geometric semantics. Defining 
these constraints only requires a small set of constraints of 
OCL, making it feasible (although not necessarily desired) 
to eliminate the dependency on OCL with limited effort. 

Next we discuss the design of the DSL in Xcore. Our 
DSL consists of a 'root' class called 'DomainModel'. This 
DomainModel class contains DomainRules. A DomainRule 
consists of 'Primitive', 'GeometricRelation', 'Geometric- 
CoordinateRelation', 'SemanticOperation' and 'Semantic- 
CoordinateOperation' . Listing 1 shows the definition of 
the primitive Point and the geometric (coordinate) relation 
PositionSemantics and PositionCoordinateSemantics. 



Listing 2 shows the definition of the PositionChange- 
Point geometric operation and the constraints (defined 
using OCL) to which this operation has to comply. 

2) Workflow and tooling: Thanks to the Xcore support 
in DSL we can make use of a Model Driven Engineering 
work flow in Eclipse. The DSL can be loaded inside Eclispe 
and converted into an ecore model and subsequently in 
an Xtext model. The tooling (such as an editor) made 
available by Xtext can be created to support the Ml 
level for the geometric semantics. The Xtext editor hereby 
allows for semantic checking of the geometric semantics 
during editing, hereby reducing application development 
time since errors are detected very early. 

B. Internal DSL 

1) DSL design: The internal DSL is built on top of 
Prolog. This way Prolog can be used to define the grammar, 
and in particular the logic constraints of the geometric 
semantics. Furthermore it provides a good mechanism 
to provide bookkeeping of the geometric primitives and 
relations in a particular application (which points, ori- 
entation frames, poses, ... are defined and check if they 
are uniquely defined). Listing 3 shows the definition of 
the geometric (coordinate) relation Position (defining both 
PositionSemantics and PositionCoordinateSemantics). 

Listing 4 shows the definition of the PositionChange- 
Point geometric operation and the constraints to which this 
operation has to comply. 

2) Workflow and tooling: The work flow is a particular 
work flow based on the Prolog language. As a tool we de- 
veloped our own editor that allows the DSL user to use the 
syntax as proposed in the geometric semantics theory [1], 
but parses it to Prolog code which is subsequently executed 
in the background to do the semantic checking. This way, 
similar functionality as obtained with the Xtext editor is 
obtained, i.e. semantic checking is done and meaningful 
error statements are produced during editing. 

VI. Example 

This section illustrates how the DSL can be used to 
prevent common errors in geometric calculations. To this 
end we use the following semantic operations: 

Position (eijC, f\D) . changePointPosition ( 

Position (e 2 |£,ei|£)). (2) 

In the above statement the lines illustrate the constraints on 
the semantic operation i.e. (we refer to the PositionCoord 
to which the operator is applied to as the subject and to the 
PositionCoord that is used as an argument in the operation 
as the argument): 1) the point of the subject has to be 
equal to the reference point of the argument, 2) the body 
of the subject has to be equal to the reference body of the 



1: Geometric 



and relation example in Xcore 



* Root class 

abstract class DomainRule { } 

* Definition of primitives 

abstract class Primitive extends DomainRule {} 
class Point extends Primitive {String name } 

* Definition of geometric (coordinate) relation Position 
abstract class GeometricRelation extends DomainRule {} 
abstract class GeometricCoordinateRelation extends DomainRuleU 
class PositionSemantics extends GeometricRelation, SuperPosition 
{ 

String name 

refers Point [1] point 

refers Body [1] body 

refers Point [1] refPoint 

refers Body [1] refBody 
} 

class PositionCoordinateSemantics extends GeometricCoordinateRelation, SuperCoordinatePosition 
{ 

String name 

@Pivot ( de r i vat ion=" self . posit ionSemantics .point" ) 

refers derived Point point 

@Pivot ( de r i vat ion=" self .posit ionSemantics .body" ) 

refers derived Body body 

@Pivot ( de r i vat ion=" self .posit ionSemantics .refPoint" ) 

refers derived Point refPoint 

@Pivot ( de r i vat ion=" self .posit ionSemantics . refBody" ) 

refers derived Body refBody 

refers PositionSemantics [1] positionSemantics 

refers OrientationFrame [1] coordFrame 



Geometric semantics operation example in Xcore 



* Definition of PositionChangePoint semantic operation and the constraints 
@Ecore (constraints="SamePoint SameBody" ) 

@Pivot (SamePoint="if notNull then self . superPosO . superPoint = self . superPosl . superRef Point else true endif", 
SameBody="if notNull then (self . superPosO . superBody = self . superPosl . superBody and self . superPosO . superBody 
self . superPosl . superRef Body) else true endif") 
class PositionChangePoint extends PositionOperation, SuperPosition 



@Pivot ( de r i vat ion=" self . superPosl . superPoint" ) 

refers derived Point point 

@Pivot ( de r i vat ion=" self . superPosO . superBody" ) 

refers derived Body body 

@Pivot ( de r i vat ion=" self . superPosO . superRef Point " ) 

refers derived Point refPoint 

@Pivot ( de r i vat ion=" self . superPosO . superRef Body" ) 

refers derived Body refBody 

@Pivot (derivation="self . superPosO <> null and self . superPosl <> null") 

derived Boolean notNull 

String name 

refers SuperPosition [1] superPosO 

refers SuperPosition [1] superPosl 



■iujLimjjjJiJiJJiiiiJiJi.mjuuimijmijmjmiJj.1^ 

% Definition of geometric (coordinate) relation Position 
position (Name, PI, P2) :- inferBody (PI, Pointl, Bodyl) , inferBody (P2, Point2, Body2) , handleParamsInit ( [Name, Pointl, 
Bodyl, Point2, Body2] , position, [position, point , body, point , body] ) , ! . 
position (Name, PI, P2, OrientationFrame) : - position (Name, positionCoordi nates, PI, P2, OrientationFrame) . 



semantics primitive 



changePoint (Result , Changee, Change) :- incrementLC, exists (Changee, Typel ) , exists (Change) , constrainChangePoint (< 

Typel, Result , Changee, Change) . 
changePoint (Result , Changee, Changel, Change2) :- incrementLC, exists (Changel) , exists (Change2 ) , exists (Changee, <-^> 

Type) , constrainChangePoint (Type, Result, Changee, Changel, Change 2 ) . 



% Constraint check for point change 

checkpoint Change (Point, Body, Change, NewPoint ) : - getPosition (Change, position, NewPoint , NewBody, NewRef Point , ^— > 
NewRefBody) , ( (NewBody = Body, NewRefPoint = Point, NewRefBody = Body) -> true ; 
writeError ( [ ' Constraint error on changing point : Position ( ' , NewPoint, ' | ' , NewBody, ' , ' , NewRefPoint, ' | ' , -f 
NewRefBody, ' ) ' , ' when Position ( ' , NewPoint, ' | ' , Body, ' , ' , Point, ' | ' , Body, ' ) was expected. ' ] ) ) . 



argument, 3) the body of the subject has to be equal to the 
body of the argument, The figures below how the Xtext 
(Figure [3} and Prolog-based (Figure [4| editor react on a 
mistake on the first constraint in the above list. As shown 
in the figures they both provide information on the kind of 
error. 

VII. Discussion 

A. Xcore versus Prolog DSL 

In this section we want to highlight some advantages 
and disadvantages of the Xcore and Prolog DSL for two 
use cases: the DSL developer and the DSL user. 

For the DSL user both the external Xcore DSL and 
internal Prolog DSL currently provide an editor that offers 
checking of the constraints defined in the DSL. However, 
because the Xcore DSL is easy to integrate into Eclipse, 
it immediately opens the way to all the tooling available 
in Eclipse. An example is the nice Xtext editor for the 
Ml level that can be generated in Eclipse from the Xcore 
DSL. Since, the Xcore DSL is however basically a text 
model, it is still possible to create any other parser or 
editor. Therefore, the Xcore DSL does not create a hard 
dependency on Eclipse or Xtext, while the tools of Eclipse 
and Xtext can still be used when desired. The tooling 
around Prolog is not as developed as around Eclipse. 
Therefore, we implemented a simple editor for the Ml level 
ourselves. While the editor only offers basic checking and 
simple error reporting, it provides all the basic functionality 
to check the constraints defined in the DSL. The Prolog 
DSL has the extra advantage that uses the Prolog language, 
which is already executable. Therefore, it is more easy 
to create executable (Prolog) code from the Ml models 
defined using the Prolog DSL. 

A DSL developer has to adapt or extend the external 
Xcore DSL and/or the internal Prolog DSL. The involved 
syntax of the OCL constraints make the Xcore DSL harder 
to 'read'. Therefore, if the readability is an issue, it could 
be decided to natively implement the constraints in Xcore 
rather than using the OCL constraints. This is feasible in 
this case since we only use a small subset of the available 
OCL constraints. Since the Prolog syntax is quite intuitive 
it makes the internal Prolog DSL easier to 'read' . 

B. Code generation: from Ml to MO 

An important limitation so far is that we have no code- 
generation support, i.e. the automatic transformation from 
the Ml to the MO level is lacking. In the robotics context 
this is an important limitation, since we need to obtain 
executable code. Moreover, preferably we want support for 
different programming languages (C++, python, . . . ) and 
execution on different types of hardware (FPGA, normal 
PC, . . . ). Therefore in future work we will also look at 
tools as Epsilon that allow to generate executable code. 



C. Future in robotics 

To ensure a future in robotics, not only code generation 
for the geometric semantics DSL is essential. Moreover, we 
need better support to write entire robotic applications 
at the Ml level. In robotics the code typically originates 
from different domains: geometry, kinematics, dynamics, 
state machines, estimators, etc. Therefore, it should be 
possible to write code that interleaves different DSLs. To 
this end, different DSL (geometric semantics DSL, compo- 
nent models, kinematic and dynamic algorithms DSL [13], 
state charts [11], motion specification DSL [9]), ...) have 
to be supported at the same time . Tools will have to be 
developed that are composable, such that it possible to, 
depending on the application, load the relevant DSLs and 
to generate code from Ml specifications that are inter- 
leaving code of different DSLs. Finally, the entire robotic 
application developed at Ml level has to be transformed to 
executable code (MO level). 

VIII. Conclusion 

In this paper we presented both an external DSL in Xcore 
and an internal DSL in Prolog for geometric relations 
between rigid bodies such as relative position, orientation, 
pose, linear velocity, angular velocity, and twist founded 
on the geometric semantics [1], [2]. These DSLs advance 
with respect to the available implementation in the general- 
purpose programming language (C++) by formalizing the 
underlying model of the geometric semantics. Furthermore, 
we showed that these DSLs are the basis tools that assist 
the robot programmers and application developers. In an 
example we showed how editors built on top of the DSLs 
automatically check the semantic correctness of geometric 
operations on rigid-body coordinate representations while 
writing and editing the code. Furthermore, it was shown 
that these editors produce meaningful error statements 
when semantic constraints are violated. We listed our 
experiences from writing the DSL up to using the editors. 
Finally, we discussed some things that are still lacking to 
integrate the geometric semantics DSL into the work flow 
of a robot programmer or application developer. 

We believe that this paper has shown that the geometric 
semantics, due to is mature but concise nature, is an 
excellent example for the development of DSLs in robotics 
and the use of these DSLs in the work flow of a robot 
programmer or application developer. 
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Fig. 3: Xtext editor example when violating the constraint that the point of the subject has to be equal to the reference 
point of the argument when applying the geometric operation changePoint. 
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1 posl= Positional |C,f|D); 

2 pos2 = Position(e2|C,e_wrong|C);| 

3 posl.changePoint[pos2); 



ERROR ON LINE 3 STATEMENT changePoint: Constraint error on changing point: Position[e2|c,e_wrong|c) when Position[e2|c,el|c) was expected. 



Fig. 4: Prolog-based editor example when violating the constraint that the point of the subject has to be equal to the 
reference point of the argument when applying the geometric operation changePoint. 
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